So far, the traffic generated in mobile networks such as e.g. GERAN and UTRAN has mostly been dominated by services that require human interaction, such as e.g. regular speech calls, web-surfing, sending MMS, doing video-chats etc, and the same traffic pattern is also anticipated for E-UTRAN. As a natural consequence, these mobile networks are designed and optimized primarily for these “Human Type Communication”, HTC, services.
There is, however, an ever-increasing market segment for Machine Type Communication, MTC, services, which do not necessarily need human interaction. MTC services include a very diverse flora of applications, ranging from, for example, vehicle applications (such as automatic emergency calls, remote diagnostics and telematics, vehicle tracking etc.) to gas and power meter readings, and also network surveillance and cameras, to just give a few examples. The requirements that MTC services put on the mobile network will without any doubt significantly differ from what is provided by today's HTC-optimized mobile networks, as outlined in 3GPP TS 22.368. The amount of MTC and HTC devices could reach a total of almost 50 billion, i.e. 50*109, by the year 2020.
Thus, in order for mobile networks such as GERAN and UTRAN to be competitive for these mass market MTC applications and devices, it is important to optimize the support of such networks for MTC communication.
One of the critical issues in e.g. GERAN is how the network could be able to distinguish and properly address such a vast number of devices for the case of simultaneous data transfer on shared radio resources, since the available addressing spaces may not be sufficient. One of the identifiers that may be a bottleneck in this respect is the so called Temporary Flow Identity, TFI, which is assigned by the GERAN network to each Temporary Block Flow, TBF, for the purpose of e.g. identifying a particular TBF and the transmitted RLC/MAC blocks associated with that TBF.
Each Temporary Block Flow is assigned a Temporary Flow Identity, TFI, value by the mobile network. This TFI value is unique among concurrent TBFs in the same direction, i.e. uplink or downlink, on all Packet Data Channels, PDCHs, used for the TBF. The same TFI value may be used concurrently for other TBFs on other PDCHs in the same direction and for TBFs in the opposite direction, and hence a TFI is a unique identifier on a given resource such as a PDCH. This limits the number of concurrent TBFs and thus the number of devices that may share the same radio resources.
The TFI itself is a 5-bit field encoded as binary number in the range 0 to 31, which is typically provided to the mobile station, MS, by the GERAN network upon assignment of the TBF.
An RLC/MAC block associated with a certain TBF is thus identified by the TFI together with, in the case of an RLC data block, the direction, uplink or downlink, in which the RLC data block is sent, and in the case of an RLC/MAC control message, by the direction in which the RLC/MAC control message is sent and the message type. If Short Sequence Number (SSN)-based Fast ACK/NACK Reporting, FANR, is used, then the TFI which identifies the TBF being acknowledged is included in the Piggy-backed ACK/NACK, see 10.3a.5 of 3GPP TS 44.060.
This means that, for example, every time an MS receives a downlink data or control block, it will use the included TFI field to determine if this block belongs to any (there can be more than one) of the TBFs associated with that very MS. If so, the block is obviously intended for this MS, whereupon the corresponding payload is decoded and delivered to upper layers, and is discarded otherwise. In the uplink direction, the behavior is the same, i.e. the mobile network uses the TFI value to identify blocks that belong to the same TBF.
The numbers of possible TFI values are limited by the available 5 bits, which thus allows for 32 individual values. This may appear sufficient, and has until now provided no significant limitation. There are however a number of indicators that the TFI addressing space may be a limiter in the future.
If a TBF is assigned to be used on more than one PDCH (which is most often the case) the number of usable TFIs per PDCH drastically decreases. Assume e.g. that all TBFs are used on all 8 PDCHs, This means that the average number of TFIs per PDCH will be 32/8=4, as compared to the 32 TFIs per PDCH that would be the case otherwise. Since it in most situations is desirable to spread a TBF over as many PDCHs in order to improve the statistical multiplexing gain and flexibility, this has the drawback of reducing the potential number of TBFs that can be supported on any given set of PDCHs, such as e.g. a Transceiver (TRX).
With recent additions to the 3GPP standards which allow the use of multiple TBFs associated with one and the same MS by means of Multiple TBF procedures as described in 3GPP TS 44.060 and/or Enhanced Multiplexing of a Single TBF (EMST) (also described in 3GPP TS 44.060), the number of TBFs associated with any given MS will no longer be limited to one per direction. One particular MS could now e.g. in the downlink have one TBF for a web-surfing session, another for an ongoing VoIP call (or an audio-streaming session with e.g. Spotify) and finally a third for a messaging service such as MSN. The benefit on splitting these particular services over different TBFs is of course that they all have different service requirements, but an obvious drawback is that more TFIs are needed.
The amount of PS, Packet Switched, traffic in a typical GERAN network is continuously and rapidly increasing already today, with the usage of classical ‘HTC’ services as described above. If, in addition, bearing in mind the anticipated ˜50 billion ‘HTC’+‘MTC’ devices in the next ten of years, it is more than likely that the PS traffic volume in GERAN, and implicitly the amount of TBFs per TRX, will increase manifold. It is not at all an unlikely situation that for these kinds of services, it would be beneficial to multiplex perhaps dozens or more users of the same uplink PDCH.